Application and Situation-Aware Community Sensing

ABSTRACT

Techniques, systems, and articles of manufacture for application and situation-aware community sensing. A method includes processing one or more sensor data requirements for each of multiple sensing applications and one or more user preferences for sensing, determining a sensing strategy for multiple sensors corresponding to the multiple sensing applications based on the one or more sensor data requirements and the one or more user preferences for sensing, wherein said sensing strategy comprises logic for executing a sensing task, and scheduling a sensor duty cycle and a sampling frequency for each of the multiple sensors based on the sensing strategy needed to execute the sensing task.

FIELD OF THE INVENTION

Embodiments of the invention generally relate to information technology,and, more particularly, to community-driven sensing techniques.

BACKGROUND

Challenges exist in community-driven sensing, namely in attempts toreduce infrastructure costs for traditional sensor networks. By way ofexample, crowd-sensing is a mechanism wherein a community is organicallyinvolved in sensing a phenomenon or event of interest. The basicblueprint of a crowd-sensing application includes a sensing agentrunning on a mobile device such as a mobile phone, while a back-endapplication (for example, a server) aggregates results and providesservices. Such applications are commonly referred to ascommunity-oriented applications (CoAs).

Accordingly, there exists interest in exploiting mobile devices as acommunity of sensors that can be utilized to sense heterogeneousphenomena ranging from sound pollution to urban social dynamics.However, designing mobile device-resident middleware for opportunisticand objective-oriented sensing of these phenomena remains a challenge.Consequently, a need exists for creating a client-side middleware thatenables a unified sensing architecture and expressivity constructs toallow for efficient control and coordination of a sensor network by aCoA based on received data.

SUMMARY

In one aspect of the present invention, techniques for application andsituation-aware community sensing are provided. An exemplarycomputer-implemented method can include steps of processing one or moresensor data requirements for each of multiple sensing applications andone or more user preferences for sensing, determining a sensing strategyfor multiple sensors corresponding to the multiple sensing applicationsbased on the one or more sensor data requirements and the one or moreuser preferences for sensing, wherein said sensing strategy compriseslogic for executing a sensing task, and scheduling a sensor duty cycleand a sampling frequency for each of the multiple sensors based on thesensing strategy needed to execute the sensing task.

In another aspect of the invention, an exemplary computer-implementedmethod can include steps of capturing one or more sensor datarequirements for each of multiple sensing applications and one or moreuser preferences for sensing, and processing the one or more sensor datarequirements and the one or more user preferences for sensing todetermine a sensing strategy for multiple sensors corresponding to themultiple sensing applications, wherein said sensing strategy compriseslogic for executing a sensing task. The method also includes schedulinga sensor duty cycle and a sampling frequency for each of the multiplesensors based on the sensing strategy needed to execute the sensingtask, and transmitting data sensed by the multiple sensors to a serverassociated with at least one of the multiple sensing applications.

Another aspect of the invention or elements thereof can be implementedin the form of an article of manufacture tangibly embodying computerreadable instructions which, when implemented, cause a computer to carryout a plurality of method steps, as described herein. Furthermore,another aspect of the invention or elements thereof can be implementedin the form of an apparatus including a memory and at least oneprocessor that is coupled to the memory and operative to perform notedmethod steps. Yet further, another aspect of the invention or elementsthereof can be implemented in the form of means for carrying out themethod steps described herein, or elements thereof; the means caninclude hardware module(s) or a combination of hardware and softwaremodules, wherein the software modules are stored in a tangiblecomputer-readable storage medium (or multiple such media).

These and other objects, features and advantages of the presentinvention will become apparent from the following detailed descriptionof illustrative embodiments thereof, which is to be read in connectionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating a platform for development, deploymentand execution of community-oriented applications, according to anembodiment of the invention;

FIG. 2 is a diagram illustrating an example schema of momentspecification, according to an embodiment of the invention;

FIG. 3 is a diagram illustrating an example snippet of a triggerspecification, according to an embodiment of the invention;

FIG. 4 is a diagram illustrating an example snippet of a utilityspecification, according to an embodiment of the invention;

FIG. 5 is a diagram illustrating an example snippet of a callbackspecification, according to an embodiment of the invention;

FIG. 6 is a block diagram illustrating an example embodiment, accordingto an aspect of the invention;

FIG. 7 is a flow diagram illustrating techniques according to anembodiment of the invention;

FIG. 8 is a flow diagram illustrating techniques according to anembodiment of the invention; and

FIG. 9 is a system diagram of an exemplary computer system on which atleast one embodiment of the invention can be implemented.

DETAILED DESCRIPTION

As described herein, an aspect of the present invention includesapplication and situation-aware community sensing. At least oneembodiment of the invention includes a utility-driven mobile device (forexample, a smart-phone) middleware for executing community-drivensensing tasks. As further detailed herein, a mobile device sensingframework in accordance with one or more embodiments of the invention isapplication-aware (that is, it adapts its operation based on demands ofthe application), user-aware (that is, it incorporates preferences,policies and/or behavioral history of the user carrying the phone orother mobile device), and situation-aware (that is, it considersresource dynamics on the device at any given point). Additionally, anaspect of the invention includes a unified device middleware tosimultaneously execute sensing tasks at moments across multipleapplications.

At least one embodiment of the invention includes sensing andpropagating events so as to respect user requirements, applicationdemands and resource constraints by balancing such considerationsthrough a unified device middleware on which different sensingapplications execute. Also, sensing requirements are modeled as moments,as described herein, and commonalities are explored for sensing andevent computation.

Applications specify sensing requirements through a declarativespecification through which an application can specify the sensing taskand associated spatio-temporal demand values associated with the task.Due to the specification, the commonalities across these requirementsare automatically determined to reduce overall sensing by re-using thesame sensed data across different applications and also to reduce thecomputation cost by deciding the level at which moments are evaluated.

Accordingly, an aspect of the invention also includes combiningrequirements across applications and optimizing execution. By way ofexample, at least one embodiment of the invention includes facilitatingsaving sensing costs as compared to duty-cycling that is imposed bymultiple parallel and disconnected applications, as well as savingprocessing costs by exploiting commonalities of execution requirementsacross applications.

FIG. 1 is a diagram illustrating a platform for development, deploymentand execution of community-oriented applications, according to anembodiment of the invention. By way of illustration, FIG. 1 depictsmobile devices 102, applications 116 and a developer 118. Additionally,FIG. 1 depicts coordination middleware 104, which includes a subscriberdatabase 106, a query parsing and decomposition component 108, asecurity and communications component 110, a data model component 112and a domain-specific policy component 114.

Such a platform as described in connection with one or more embodimentsof the invention includes a cloud-based coordination middleware tojointly harness the sensing potential in the mobile devices and harvestthe necessary sensor data recorded by the sensors. The playersassociated with CoAs form an ecosystem that is a producer-consumerecosystem with controlling stakeholders administering the flow ofinformation between the producers and the consumers based on certainobjectives. The producers in a system such as depicted in FIG. 1 are thesensors embedded in the mobile devices 102 of the participating users.The consumers are the CoAs, which provide appropriate services to theirusers based on the data.

The middleware 104 as depicted in FIG. 1 parses a query (via component108) and sends out sensing tasks to individual mobile devices 102 (usinga specification called moments, as further described herein). Themiddleware 104 collects data, builds data models (via component 112) andresponds to queries. Also, the middleware 104 computes spatio-temporalcharacteristics of the data demands of CoAs hosted in the platform andprovides inputs to clients pertaining to the demand. The clients canconsider the input and autonomously decide on sensing policies,depending on other client-specific requirements and constraints (forexample, user preferences and resources available). Additionally, themiddleware 104 stores domain-specific policies 114 and manages messagingand communications 110 with the mobile end points.

To use middleware, in accordance with at least one embodiment of thepresent invention, a CoA developer can specify a sensing task using anabstract data type referred to herein as a moment. A moment firstspecifies the processing requirements using declarative primitives as acomputation on top of the sensor data. The computations are typicallymathematical operations on a quantized form of the data (for example,quantization of five seconds). A moment can be defined over multiplesensors and can be a combination of pre-defined moments, and frequentlyused moments can be made readily available to the developers using alibrary. During application deployment time, moments corresponding tothe application are registered with the individual middleware instancesresiding in the mobile devices. Thereafter, the middleware managesexecution of the moments and transmits events back to the CoA. CoAs canperiodically update the installed moment specification to register newrequirements.

Conceptually, a sensing moment encapsulates the logic to define an eventof interest and its associated value to the CoA. Accordingly, in atleast one embodiment of the invention, a moment specification includesrepresentation constructs along three dimensions: (i) criteria toascertain that something of interest has transpired, (ii) data that needto be reported and data routing details, and (iii) spatio-temporalutility of the data as perceived by the CoA so that the overall sensingtask can be optimized. Based on these considerations, at least oneembodiment of the invention includes a moment specification thatcontains a trigger to specify the criteria (events of interest) whendata are to be reported, a utility function to specify thespatio-temporal utility of the sensing task, and a callback feature tospecify the data to be reported and how that data is to be sent.

FIG. 2 is a diagram illustrating an example schema of momentspecification 202, according to an embodiment of the invention. Asdetailed herein, an extensible markup language (XML) schema is used todefine the structure and various constructs of the task specificationlanguage. Each task specification is thus an XML document conforming tothis schema.

Criteria of occurrence for a moment are specified by a CoA developerusing a trigger. By way of example, an application can be interested inobtaining data periodically, or when some condition (either based on rawsensor values or involving a higher level function on top of raw values)is evaluated as true. Accordingly, in at least one embodiment of theinvention, such a trigger has a schedule construct and a conditionconstruct, either or both of which can be used on a given sensor. Aschedule construct, for example, is used for periodic reporting and hasa start date and an end date between which the events would be reported,and a duration to specify the periodicity of the event.

An event condition is modeled as a logical expression with Boolean andrelational operators applied to operands. The operands can be raw sensorvalues represented by sensor attributes, or can be a derived valuecomputed from the raw sensor values. At least one embodiment of theinvention includes enabling an application developer to declarativelyspecify the computation procedure on raw sensor values. Anotheradvantage of such a specification is that the same sensing taskspecification can be used for all mobile operating system (OS)platforms.

FIG. 3 is a diagram illustrating an example snippet of a triggerspecification 302, according to an embodiment of the invention.Specifically, FIG. 3 depicts a trigger specification containing an eventcondition on global positioning system (GPS) and Bluetooth sensors. Theevents across sensors are defined to be “AND,” that is, the overallevent is true only when all individual sensor events are true.

Additionally, in at least one embodiment of the invention, momentspecification also provides auxiliary occurrence criteria that can beexpressed for a trigger having an event condition. Such auxiliaryparameters can be organized under categories that include time-based,toggle-based, and/or persistence-based. In the case of time-based, atime period is specified that pertains to the minimum duration betweentwo reports of events (even if the condition is satisfied in-between).For toggle-based, the current “true” evaluation of the condition isreported only if the last evaluation was “false” (for example, toprovide an alert only when a user enters or leaves a geographic zone).For the persistence-based criteria, a minimum time period is providedfor which the condition has to be continuously true (for example, toreport only when a sound level is beyond a threshold for a certainamount of time). Depending on the requirement, one or more of theseparameters can be used to further qualify a moment occurrence.

A sensing task may have different utility than an application based onthe time of day and/or the location of a user. For example, a CoAinterested in monitoring noise in a city might not need readings inareas where it (that is, the CoA) already has sufficient data formodeling or if the phenomenon is relatively invariant. Similarly, a CoAmight only be interested in monitoring the sound levels in a city duringevening time. Hence, the middleware of one or more embodiments of theinvention includes not activating (or de-activating) sensors at certaintimes to save on energy and/or computing resources of a mobile device.

At least one embodiment of the invention includes modeling the CoA'sutility criteria through a utility function construct that is acollection of utility elements. Each utility element contains a utilityvalue between 0 and 1, as well as the associated time period, userlocation or both. Accordingly, each utility element can serve to capturethe CoA's perceived utility at different times of day and/or at variousgeographical locations. By way of example, a time period can berepresented as a start and end time for which that utility value isvalid, and a geographical location can be represented as any closedgeographical region modeled as a set of points (in order) which areconnected.

FIG. 4 is a diagram illustrating an example snippet of a utilityspecification 402, according to an embodiment of the invention.Specifically, FIG. 4 depicts a utility function specification where theutility of sensed data is 0.8 between 9:00 AM to 6:00 PM, and only whenthe user is within 50 kilometers (km) of the specified center location.At any other time, or if the user is outside the specified region, theutility of sensed data is 0. As is to be appreciated, the particularphysical interpretation of a given utility value on the 0-1 scale can bebased, for example, on a contract between the CoA developer and thespecific middleware instance realization.

In at least one embodiment of the invention, a CoA specifies whichsensor values are reported back when an event occurs. For example, anapplication might be interested in the location (for example, GPScoordinates) when the sound decibel level crosses a particularthreshold. Further, the manner by which such values are to be routed tothe corresponding CoA can also be specified. In at least one embodimentof the invention, this information is captured through a callbackelement, which includes a uniform resource identifier (URI) attributethat provides the uniform resource locator (URL) where the sensedinformation is to be reported.

FIG. 5 is a diagram illustrating an example snippet of a callbackspecification 502, according to an embodiment of the invention. Inaccordance with the example depicted in FIG. 5, various reporting modelscan be implemented. The information to be passed is specified by one ormore sensor input elements, which each have an attribute name that givesthe name of the sensor and one or more attribute elements that give theactual information to be reported. The example in FIG. 5 depicts how tospecify latitude and longitude values of a GPS sensor.

FIG. 6 is a block diagram illustrating an example embodiment, accordingto an aspect of the invention. Specifically, FIG. 6 illustrates thelayered architecture of the middleware, as described herein. As depictedin the figure, the sensing agent 610 is a client-side application thatcan be deployed by each CoA. The sensing agent 610 interacts with theback-end application server of the CoA to receive the momentspecification, and sends back the appropriate data sensed by middlewareto the back-end server. Further, preferences (privacy restrictions,battery budget allowed, etc.) of the user 612 are captured and fed intothe middleware via the sensing agent 610.

With respect to CoAs, each CoA is assumed to be running on a server-sideplatform that aggregates results from multiple participants and executesseveral application-specific control instructions on the data (forexample, tasking, communications and collaborations). Additionally, eachparticipating mobile device user 612 has a common device-side clientthat enables the user and his or her mobile device (for example, asmart-phone) to participate and collaborate in the CoA. A device clientis an application (app) that can, for example, be downloaded onto theuser's device. Also, when a user subscribes to a new CoA, the policiesfor participation of the device are downloaded and configured on theclient, and a device-side application proxy stores app-specificinstructions and communicates with the common device-side client.Thereafter, the common device agent manages the communication andsensing tasks while being sensitive to the user's usage profile on thedevice, the demands from the back-end applications, the user's perceivedvalue of participation, and energy usage.

Referring back to FIG. 6, the middleware includes an interaction layer608, a computation and analysis layer 606, and a sensor control layer604. As described herein, the interaction layer 608 includesspecifications of an application's requirements (what to sense, andwhen), user preferences, as well as rules that specify how to extractrich presence/semantics from raw sensor data. Additionally, thecomputation and analysis layer 606 evaluates registered requirementsagainst available sensor data, learns a user's sensor data history, anddetermines a sensing strategy. Further, the sensor control layer 604,via sensor controller component 614, controls access to sensors (at ahardware level), implements a sensing strategy, and transmits data to autility layer.

The interaction layer 608 reads in the sensor data requirements for theCoAs and the user preferences for sensing, and passes such informationto the underlying computation and analysis layer 606 for data obtainmentfrom the sensors. Within the interaction layer, 608, the user preferencemodule 628 stores the policies specified by the users. The userpreferences are used as constraints by the underlying layers todetermine a sensing plan. For example, a user may want to specify thatthe sensing activity should be reduced when the battery level of thedevice falls below 50%, and all sensing be stopped if the battery levelis less than 20%. In another example, a user may wish to stop anysensing activity between 9:00 AM and 5:00 PM, or if the user isphysically located at his or her office.

For CoAs, user preferences can be classified into categories such astime-based, location-based, and resource-based user preferences. Fortime-based criteria, the user can specify different time periods forwhich the sensing activity should be stopped (or started). The criteriacan be modeled, by way of example, as a collection of different timeperiods, with each period having a start time and an end time. Forlocation-based criteria, the user can specify a location (such as anoffice location) as a circular region in terms of latitude and longitudewhere sensing should be disabled (or enabled). For resource-basedcriteria, a user can specify, for example, different device batterylevels for different sensing behavior. For instance, at a battery levelbelow a user-specified threshold, the sensing activity can be stoppedcompletely or certain sensors restricted from being invoked. Anotherresource is the mobile device's data connection, and a user couldspecify, for example, which connection (for example, Wi-Fi) should beused for data upload.

As also within the interaction layer 608, the sensing moment repository626 collects a list of moments received from the sensing agent 610 andstores the moments along with the corresponding binding or callbackinformation before passing the moments to the computation and analysislayer 606. The repository 626 may also store other book-keepinginformation related to the moments. The event dispatcher module 624 isan engine that makes use of the callback information and dispatches therelevant data corresponding to an occurrence of a moment.

The computation and analysis layer 606 is responsible for devisingefficient management policies for executing the moments. The momentstransmitted by the interaction layer 608 are used by a moment evaluatormodule 616 and a sensing planner module 622. The moment evaluator module616 implements the logic required to compute occurrences of the moments.The logic of a moment can be rule-based and/or learning-based.Rule-based evaluations extract attributes specified during theapplication development time. Learning-based evaluations correspond tothe events that are evaluated with pre-built machine learning tools.

Because such computations need a window of data sensed over a certainperiod of time, the moment evaluator module 616 maintains a buffer 618for each of the sensors. The buffers 618 are (continuously) populatedwith data sensed by the underlying sensor control layer 604. The size ofa buffer 618 depends on the logic implemented by the moment evaluatormodule 616 and, hence, is a programmable parameter for the middleware.The sensing moment repository 626 reuses the common moment computationsamong the various CoAs, and saves compute and storage resources in themiddleware.

Also, as further described herein, moment evaluation time, value and atimestamp can be obtained to build moment profiles, and raw sensor datareceived from lower modules can be obtained to build sensor profiles viamodule 620.

With respect to evaluating moments, at least one embodiment of theinvention includes expressing moments using conjunctive normal form(CNF). All moment rules are merged together to build a commonhierarchical structure for evaluating rules, and a quantitative marginof tolerance value is assigned for each attribute in a moment. Thisprovides a quantitative estimate (time) of the amount of relaxation therule can assume while evaluating stale data.

Each application can specify a tolerance limit criteria in the momentdefinition. By way of example, a tolerance limit may specify how stalethe rest of a particular item of data, on which the evaluation of themoment is dependent, can become. At least one embodiment of theinvention defines limits including sensor-specific limits andmoment-specific limits. Sensor specific limits may specify, for examplehow stale GPS data can be when any other dependent data have arrived.Moment-specific limits may specify how stale any set of data can be whenany other dependent data have arrived. As noted above, the momentevaluator module 616 has a buffer 618 for each sensor which holds themost recent value received from that sensor.

The sensing planner module 622 provides intelligence for the sensingstrategy or policy of the sensors. A sensing strategy of a sensorspecifies whether a particular instance of time and space is suitablefor sensing data from the sensor. The efficiency of the strategy ismeasured by an objective function that takes into account the demand ofthe data item at an instance of time and space, obtained through momentspecification updates from the back-end server (application-awareness),after discounting the associated cost for sensing in terms of resourcesconsumed (situation-awareness) and the constraints imposed by the usersowning the sensors (user-awareness). That is, the sensing planner module622 can consider information such as the current set of moments,profile/history of sensor data and moment occurrences, user preferencesand sensing costs in determining the desired duty cycle of the sensors.

Additionally, the sensing planner module 622 implements an appropriatesensing strategy that optimizes the objective function. Because of theinherent uncertainty associated with unbounded data sensed from thephysical world, the optimization of such objective functions is acomputationally hard problem and various heuristic-based solutions canbe implemented. At least one embodiment of the invention includesanalyzing historical data for previously observed trends and bounds andusing such data to reduce the uncertainty.

The sensor and moment profiler module 620 stores such historical datafor the sensing planner module 622 to use. Historical data can bestored, for example, as a time series of moment evaluation results or asa time series of raw sensor data depending on the storage available tothe sensor and moment profiler module 620. As detailed further herein,the sensing planner module 622 makes use of parameters that includesampling frequency and duty cycle, as exposed by the underlying sensorcontrol layer 604, to implement a sensing strategy.

The sensor control layer 604 acts as an interface to the sensor hardware602 (which can include Wi-Fi, GPS, etc.) and schedules the sensor dutycycle and sampling frequency for a sensor according to the sensorstrategy devised by the sensing planner module 622. Duty cycle refers tothe ratio between the time period for which a sensor is turned OFF (thatis, not actively sensing) and the time period for which the sensor isturned ON (that is, actively sensing). The sampling frequency for asensor refers to the frequency at which data are sensed when the sensoris ON. Low-level platform-specific application programming interfaces(APIs) for various sensors are used to program a sensor with therequired sampling frequency and duty cycle.

The sensor control layer 604 also exposes higher-level APIs to thecomputation and analysis layer 606 for that layer to specify the desiredduty cycle and sampling frequency for a sensor. The APIs can beon-demand or periodic in nature. Additionally, the sensor control layer604 is also responsible for sending the data recorded by the sensors 602to the buffers 618 of the moment evaluator module 616 for evaluation ofthe relevant moments. Further, the sensor control layer 604 also reportsthe associated cost of invocation to the computation and analysis layer606. This information (in addition to other information) is used by thesensing planner module 622 to periodically determine or update anappropriate sensing strategy.

FIG. 7 is a flow diagram illustrating techniques according to anembodiment of the present invention. Step 702 includes processing one ormore sensor data requirements for each of multiple sensing applicationsand one or more user preferences for sensing. The sensor datarequirements can include sensed event criteria, a spatio-temporalutility function for an event to be sensed, and/or specifications forreporting sensor information. Additionally, the user preferences caninclude a time-based preference, a location-based preference, and/or aresource-based preference.

Step 704 includes determining a sensing strategy for multiple sensors(for example, GPS, Bluetooth, etc.) corresponding to the multiplesensing applications (CoAs) based on the one or more sensor datarequirements and the one or more user preferences for sensing, whereinsaid sensing strategy comprises logic for executing a sensing task.Determining can include evaluating the sensor data requirements againstavailable sensor data, as well as learning sensor data history for theuser and/or one or more different applications. Additionally, a sensingstrategy specifies a period of time and/or a geographic locationsuitable for a sensor to actively sense data. Further, as detailedherein, a sensing strategy reduces resource consumption while satisfyingone or more user preferences and one or more application requirements.

Step 706 includes scheduling a sensor duty cycle and a samplingfrequency for each of the multiple sensors based on the sensing strategyneeded to execute the sensing task. As detailed herein, a sensor dutycycle includes a ratio between a time period for which a sensor is notactively sensing and a time period for which the sensor is activelysensing. Also, a sampling frequency comprises a frequency at which dataare sensed when a sensor is actively sensing.

The techniques depicted in FIG. 7 can also include storing the sensordata requirements for the sensing application and the user preferencesfor sensing. Further, at least one embodiment of the invention includesmaintaining a buffer for each of the multiple sensors, wherein eachbuffer is continuously populated with data sensed by the correspondingsensor.

FIG. 8 is a flow diagram illustrating techniques according to anembodiment of the invention. Step 802 includes capturing one or moresensor data requirements for each of multiple sensing applications andone or more user preferences for sensing. Step 804 includes processingthe one or more sensor data requirements and the one or more userpreferences for sensing to determine a sensing strategy for multiplesensors (for example, GPS, Bluetooth, etc.) corresponding to themultiple sensing applications (CoAs), wherein said sensing strategycomprises logic for executing a sensing task.

Step 806 includes scheduling a sensor duty cycle and a samplingfrequency for each of the multiple sensors based on the sensing strategyneeded to execute the sensing task. Step 808 includes transmitting datasensed by the multiple sensors to a server associated with at least oneof the multiple sensing applications.

The techniques depicted in FIG. 7 and FIG. 8 can also, as describedherein, include providing a system, wherein the system includes distinctsoftware modules, each of the distinct software modules being embodiedon a tangible computer-readable recordable storage medium. All of themodules (or any subset thereof) can be on the same medium, or each canbe on a different medium, for example. The modules can include any orall of the components shown in the figures and/or described herein. Inan aspect of the invention, the modules can run, for example, on ahardware processor. The method steps can then be carried out using thedistinct software modules of the system, as described above, executingon a hardware processor. Further, a computer program product can includea tangible computer-readable recordable storage medium with code adaptedto be executed to carry out at least one method step described herein,including the provision of the system with the distinct softwaremodules.

Additionally, the techniques depicted in FIG. 7 and FIG. 8 can beimplemented via a computer program product that can include computeruseable program code that is stored in a computer readable storagemedium in a data processing system, and wherein the computer useableprogram code was downloaded over a network from a remote data processingsystem. Also, in an aspect of the invention, the computer programproduct can include computer useable program code that is stored in acomputer readable storage medium in a server data processing system, andwherein the computer useable program code is downloaded over a networkto a remote data processing system for use in a computer readablestorage medium with the remote system.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in a computer readable medium havingcomputer readable program code embodied thereon.

An aspect of the invention or elements thereof can be implemented in theform of an apparatus including a memory and at least one processor thatis coupled to the memory and operative to perform exemplary methodsteps.

Additionally, an aspect of the present invention can make use ofsoftware running on a general purpose computer or workstation. Withreference to FIG. 9, such an implementation might employ, for example, aprocessor 902, a memory 904, and an input/output interface formed, forexample, by a display 906 and a keyboard 908. The term “processor” asused herein is intended to include any processing device, such as, forexample, one that includes a CPU (central processing unit) and/or otherforms of processing circuitry. Further, the term “processor” may referto more than one individual processor. The term “memory” is intended toinclude memory associated with a processor or CPU, such as, for example,RAM (random access memory), ROM (read only memory), a fixed memorydevice (for example, hard drive), a removable memory device (forexample, diskette), a flash memory and the like. In addition, the phrase“input/output interface” as used herein, is intended to include, forexample, a mechanism for inputting data to the processing unit (forexample, mouse), and a mechanism for providing results associated withthe processing unit (for example, printer). The processor 902, memory904, and input/output interface such as display 906 and keyboard 908 canbe interconnected, for example, via bus 910 as part of a data processingunit 912. Suitable interconnections, for example via bus 910, can alsobe provided to a network interface 914, such as a network card, whichcan be provided to interface with a computer network, and to a mediainterface 916, such as a diskette or CD-ROM drive, which can be providedto interface with media 918.

Accordingly, computer software including instructions or code forperforming the methodologies of the invention, as described herein, maybe stored in associated memory devices (for example, ROM, fixed orremovable memory) and, when ready to be utilized, loaded in part or inwhole (for example, into RAM) and implemented by a CPU. Such softwarecould include, but is not limited to, firmware, resident software,microcode, and the like.

A data processing system suitable for storing and/or executing programcode will include at least one processor 902 coupled directly orindirectly to memory elements 904 through a system bus 910. The memoryelements can include local memory employed during actual implementationof the program code, bulk storage, and cache memories which providetemporary storage of at least some program code in order to reduce thenumber of times code must be retrieved from bulk storage duringimplementation.

Input/output or I/O devices (including but not limited to keyboards 908,displays 906, pointing devices, and the like) can be coupled to thesystem either directly (such as via bus 910) or through intervening I/Ocontrollers (omitted for clarity).

Network adapters such as network interface 914 may also be coupled tothe system to enable the data processing system to become coupled toother data processing systems or remote printers or storage devicesthrough intervening private or public networks. Modems, cable modem andEthernet cards are just a few of the currently available types ofnetwork adapters.

As used herein, including the claims, a “server” includes a physicaldata processing system (for example, system 912 as shown in FIG. 9)running a server program. It will be understood that such a physicalserver may or may not include a display and keyboard.

As noted, aspects of the present invention may take the form of acomputer program product embodied in a computer readable medium havingcomputer readable program code embodied thereon. Also, any combinationof computer readable media may be utilized. The computer readable mediummay be a computer readable signal medium or a computer readable storagemedium. A computer readable storage medium may be, for example, but notlimited to, an electronic, magnetic, optical, electromagnetic, infrared,or semiconductor system, apparatus, or device, or any suitablecombination of the foregoing. More specific examples (a non-exhaustivelist) of the computer readable storage medium would include thefollowing: an electrical connection having one or more wires, a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), an optical fiber, a portable compact disc read-onlymemory (CD-ROM), an optical storage device, a magnetic storage device,or any suitable combination of the foregoing. In the context of thisdocument, a computer readable storage medium may be any tangible mediumthat can contain, or store a program for use by or in connection with aninstruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing an appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of at least oneprogramming language, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks. Accordingly, an aspect of the inventionincludes an article of manufacture tangibly embodying computer readableinstructions which, when implemented, cause a computer to carry out aplurality of method steps as described herein.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, component, segment,or portion of code, which comprises at least one executable instructionfor implementing the specified logical function(s). It should also benoted that, in some alternative implementations, the functions noted inthe block may occur out of the order noted in the figures. For example,two blocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

It should be noted that any of the methods described herein can includean additional step of providing a system comprising distinct softwaremodules embodied on a computer readable storage medium; the modules caninclude, for example, any or all of the components detailed herein. Themethod steps can then be carried out using the distinct software modulesand/or sub-modules of the system, as described above, executing on ahardware processor 902. Further, a computer program product can includea computer-readable storage medium with code adapted to be implementedto carry out at least one method step described herein, including theprovision of the system with the distinct software modules.

In any case, it should be understood that the components illustratedherein may be implemented in various forms of hardware, software, orcombinations thereof, for example, application specific integratedcircuit(s) (ASICS), functional circuitry, an appropriately programmedgeneral purpose digital computer with associated memory, and the like.Given the teachings of the invention provided herein, one of ordinaryskill in the related art will be able to contemplate otherimplementations of the components of the invention.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a,” “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition ofanother feature, integer, step, operation, element, component, and/orgroup thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed.

At least one aspect of the present invention may provide a beneficialeffect such as, for example, sensing and propagating events so as torespect user requirements, application demands and resource constraintsby balancing such considerations through a unified device middleware onwhich different sensing applications execute.

The descriptions of the various embodiments of the present inventionhave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

What is claimed is:
 1. A method comprising: processing one or moresensor data requirements for each of multiple sensing applications andone or more user preferences for sensing; determining a sensing strategyfor multiple sensors corresponding to the multiple sensing applicationsbased on the one or more sensor data requirements and the one or moreuser preferences for sensing, wherein said sensing strategy compriseslogic for executing a sensing task; and scheduling a sensor duty cycleand a sampling frequency for each of the multiple sensors based on thesensing strategy needed to execute the sensing task; wherein at leastone of the steps is carried out by a computer device.
 2. The method ofclaim 1, wherein the one or more sensor data requirements comprisesensed event criteria.
 3. The method of claim 1, wherein the one or moresensor data requirements comprise a spatio-temporal utility function foran event to be sensed.
 4. The method of claim 1, wherein the one or moresensor data requirements comprise one or more specifications forreporting sensor information.
 5. The method of claim 1, wherein the oneor more user preferences comprise a time-based preference.
 6. The methodof claim 1, wherein the one or more user preferences comprise alocation-based preference.
 7. The method of claim 1, wherein the one ormore user preferences comprise a resource-based preference.
 8. Themethod of claim 1, wherein said sensing strategy reduces resourceconsumption while satisfying the one or more user preferences and theone or more application requirements.
 9. The method of claim 1, whereinsaid sensing comprises utilizing multiple user mobile devices.
 10. Themethod of claim 1, wherein said determining comprises evaluating the oneor more sensor data requirements against available sensor data.
 11. Themethod of claim 1, wherein said determining comprises learning sensordata history for the user and/or one or more different sensingapplications.
 12. The method of claim 1, wherein said sensing strategyspecifies a period of time and/or a geographic location suitable for asensor to actively sense data.
 13. The method of claim 1, comprising:storing the one or more sensor data requirements for each sensingapplication and the one or more user preferences for sensing.
 14. Themethod of claim 1, comprising: maintaining a buffer for each of themultiple sensors, wherein each buffer is continuously populated withdata sensed by the corresponding sensor.
 15. An article of manufacturecomprising a computer readable storage medium having computer readableinstructions tangibly embodied thereon which, when implemented, cause acomputer to carry out a plurality of method steps comprising: processingone or more sensor data requirements for each of multiple sensingapplications and one or more user preferences for sensing; determining asensing strategy for multiple sensors corresponding to the multiplesensing applications based on the one or more sensor data requirementsand the one or more user preferences for sensing, wherein said sensingstrategy comprises logic for executing a sensing task; and scheduling asensor duty cycle and a sampling frequency for each of the multiplesensors based on the sensing strategy needed to execute the sensingtask.
 16. The article of manufacture of claim 15, wherein said sensingcomprise utilizing multiple user mobile devices.
 17. A systemcomprising: at least one distinct software module, each distinctsoftware module being embodied on a tangible computer-readable medium; amemory; and at least one processor coupled to the memory and operativefor: processing one or more sensor data requirements for each ofmultiple sensing applications and one or more user preferences forsensing; determining a sensing strategy for multiple sensorscorresponding to the multiple sensing applications based on the one ormore sensor data requirements and the one or more user preferences forsensing, wherein said sensing strategy comprises logic for executing asensing task; and scheduling a sensor duty cycle and a samplingfrequency for each of the multiple sensors based on the sensing strategyneeded to execute the sensing task.
 18. The system of claim 17, whereinsaid sensing strategy reduces resource consumption while satisfying theone or more user preferences and the one or more applicationrequirements.
 19. A method comprising: capturing one or more sensor datarequirements for each of multiple sensing applications and one or moreuser preferences for sensing; processing the one or more sensor datarequirements and the one or more user preferences for sensing todetermine a sensing strategy for multiple sensors corresponding to themultiple sensing applications, wherein said sensing strategy compriseslogic for executing a sensing task; scheduling a sensor duty cycle and asampling frequency for each of the multiple sensors based on the sensingstrategy needed to execute the sensing task; and transmitting datasensed by the multiple sensors to a server associated with at least oneof the multiple sensing applications; wherein at least one of the stepsis carried out by a computer device.
 20. The method of claim 19, whereinsaid sensing comprise utilizing multiple user mobile devices.